Field of the Invention
The present invention relates to transaction server management and more particularly to transaction server performance monitoring.
Description of the Related Art
A transaction server manages business transactions over a computer communications network. The transaction server typically is positioned between the client computing device and the application server providing the business application logic and acts as glue, holding essential data processing activities together. Importantly, the transaction server allows an enormous volume of information to remain accurate and ensures transactions are completed without interruption or data corruption. To achieve the foregoing, generally a transaction server provides for “roll back” capability through the implementation of the “ACID” set of properties—namely atomicity, consistency, isolation and durability. Thus, the transaction server is responsible for maintaining high performance, availability and data integrity and ensures that no computer has too much or too little to do.
A transaction server can be a software application executing in memory of a computer forming a composite device, or a transaction server can be a software application executing in memory of a computer also hosting the execution of other applications, whether in the same process address space or in a separate process address space, such as in a separate virtual machine. An example of a transaction server is the “customer information control system” (CICS) online transaction processing application. CICS along with the COBOL programming language has provided the backbone of enterprise mainframe computing for several decades and more recently has been supported in the mid-range and network personal computing environments.
In a transaction server environment, the health and stability of the transaction server can be measured according to many different measurable metrics. Most traditionally, log messages can be examined in which abnormal events or conditions have been reported. Also, independent monitoring logic can monitor system resources in order to generate an alert or to log a message when a threshold has been exceeded in any given resource including memory or processor usage. Yet further, performance metrics can be captured during the operation of the transaction server and analyzed at a later time to retro-reflectively identify poor health of the transaction server. Finally, of course, end user feedback of slow performance can always act as an impetus for identifying poor health in a transaction server.
Nevertheless, in all circumstances, conventional health monitoring methodologies are retrospective resulting in a determination of poor health only after the failure in the transaction server has occurred. Yet, in many cases awaiting a retrospective identification of poor health in a transaction server can be too little too late. Further, the failing state of a transaction server may not be evident from monitoring the successful completion of transactions whose successful completion may not be indicative of internally failing components of the transaction server.